| From: | Ben Hutchings |
| Date: | 04 Aug 99 at 00:49:28 |
| Subject: | Re: Re: (no subject) |
From: Ben Hutchings <womble@zzumbouk.demon.co.uk>
On Sat, Jul 31, 1999 at 01:31:12PM +0100, Tim Hanson wrote:
> From: Tim Hanson <msinister@connectfree.co.uk>
>
> Amiga-C wrote this on 08-Jul-99 at 17:29:01
> Hi Amiga-C
>
> -> 1. Why are global variables bad ideas ????
> -> 2. When creating a shared library why can't I use dos.library functions
> -> (Open,Close,etc...) ????
> -> 3. How can I find a bug if my code is syntaticly correct but the program
> -> crashes when it's run ????
>
> 1.Mainly because they can introduce bugs which are hard to find. If a
> local variable turns out to contain spurious data you know which piece of
> code is to blame. They also make code less readable IMHO.
There's nothing inherently wrong with global variables. However, it
is good practice to restrict the scope of variables as much as is
reasonable - firstly to avoid name clashes, and secondly to limit
access to them. In C you can use `static' to restrict them to a
single translation unit; in C++ namespaces (classes are a special kind
of namespace) limit visibility and access specifiers (`private' and
`protected') limit access.
> 2. No idea about this. Is it safe to call a shared library function from
> within a shared library at all. I`ve never tried writing libraries. If anyone
> knows more about this I for one would be interested to hear.
It should be safe as long as the dependency is properly documented.
However, generating correct in-line calls may require some fiddling
with compiler-specific options.
> 3. Run it through a debugger, put lots of printf()s for important
> variables. Also try enforcer/cyberguard and mungwall or equivalent. Develop a
> very bad headache. Good Luck.
In certain tight situations, SAD (see exec.doc) may be useful. I
don't know of any debuggers that support remote debugging through SAD
though.